Decided to build in auth, going to draft to test it

Auth is tested and working

@jcat4 can you rebase on main and resolve conflicts? seems to be largely the model_context_protocol => mcp rename

Thank you for your work on this, @jcat4. We're looking forward to seeing it merged. Is there an expected timeline for this?

@jcat4 can you rebase on main and resolve conflicts? seems to be largely the model_context_protocol => mcp rename

Sorry, lost track of this.

I thought we wanted to go with the pluggable approach? If so, I can close this

Or I can try to rework this to be closer to what y'all envisioned!

@jcat4 @topherbullock Now that #27 is in, could we revisit this and get a client in there? 🙏

@jcat4 @topherbullock Now that #27 is in, could we revisit this and get a client in there? 🙏

I'll make some time this week to knock this out

Unsure if we still feel strongly about going with a pluggable approach, and haven't had any feedback on that yet. Will put this as-is in for review

But please let me know if we should go somewhere else with the interface! I want us to get as close to right as possible on our first release

I've tested the new code in one of our local apps, and it's working as expected.

Spoke with @juharris, and we decided a pluggable approach would probably be better. The primary reason is it will allow folks to implement and pass their own custom transport layers (and open the door for other gems to add more, too!). The first step might be a bit manual (create your transport, create your client by passing your transport, send messages to your client), but we can iterate later with convenience wrappers that won't break existing code

Overall, it seems like the safer bet. What we have is functional, but maybe not flexible enough for a public gem. Will begin work on this again next week when I have time, I think I can knock something out relatively quickly

@jcat4 Thanks for doing this!

@jcat4 can you fix up the suggestions and squash your commits pls? Thanks for pushing this through!

Thank you for the client implementation. I've left some minor feedback. Since it doesn’t seem to be squashed yet, please squash your commits into one at the end.

Since this is a user-specific setting, I think it should be defined in the developer's ~/.gitignore rather than in the repository.

@koic My view: if we never want a file committed, the repo should enforce it so we don’t rely on each contributor’s local setup. Is there a strong reason to prefer user-level ignores here?

Because these are specific to the user's development environment (such as OS or editor) and not specific to the Ruby SDK. For more details, please refer to the discussion in the following closed PRs:
https://github.com/rails/rails/pulls?q=is%3Apr+.DS_Store+is%3Aclosed+

Because these are specific to the user's development environment (such as OS or editor) and not specific to the Ruby SDK. For more details, please refer to the discussion in the following closed PRs: https://github.com/rails/rails/pulls?q=is%3Apr+.DS_Store+is%3Aclosed+

Thanks for this! Hmmm... I do see that's how rails operates. If this is commonly how other open source ruby repos operate, I can make this change to be more inline.

But I do wanna say, I still personally disagree, as I think this change could avoid friction. Those 14 PRs in rails where this convo had to happen are examples of friction that could be avoided.

If you have any docs or anything on hand, would love to know more about why we want to have a platform-agnostic .gitignore!

I'm personally convinced by the reasoning in the Rails repository, so I don't have any additional documentation beyond that. In any case, this doesn't seem to be the main focus of this PR. This point can serve as a starting place for the PR itself. I do have a bit of feedback, so I'll leave some additional comments.